Field
The present disclosure relates to communication networks. More specifically, the present disclosure relates to a method for a constructing a scalable, multi-version system.
Related Art
The exponential growth of the Internet has made it a popular delivery medium for a variety of applications running on physical and virtual devices. Such applications have brought with them an increasing demand for bandwidth. As a result, equipment vendors race to build larger and faster switches with versatile capabilities. However, the size of a switch cannot grow infinitely. It is limited by physical space, power consumption, and design complexity, to name a few factors. Furthermore, switches with higher capability are usually more complex and expensive. More importantly, because an overly large and complex system often does not provide economy of scale, simply increasing the size and capability of a switch may prove economically unviable due to the increased per-port cost.
A flexible way to improve the scalability of a switch system is to build a fabric switch. A fabric switch is a collection of individual member switches. These member switches form a single, logical switch that can have an arbitrary number of ports and an arbitrary topology. As demands grow, customers can adopt a “pay as you grow” approach to scale up the capacity of the fabric switch. However, these member switches typically have the same software version to operate as a single switch. As a result, a switch with an updated software version may not operate as a member switch with switches with an older software version. Hence, a software version update may not be performed gradually while keeping a respective member switch operational in the fabric switch.
Meanwhile, a switch, an individual or a member switch of a fabric switch, continues to store more configuration information as the switch participates in network virtualizations, partitions, and switch groups, and operates on a plurality of network protocols of different network layers. This configuration needs to be applied to the switch when the switch powers up, and thus, should be persistent. A switch typically stores such configuration information in a local storage in an unstructured format. The switch reads the information during booting up (i.e., powering up), and loads the information into memory. Managing persistent storage in unstructured format is inefficient and requires runtime structuring.
While persistent storage brings many desirable features to a switch, some issues remain unsolved in efficiently facilitating interoperability of multiple software versions in a switch group.